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Dynamic binding 


We can overwrite super class methods with our own 


definitions! Consider the Clock class again: 


public class Clock 


if 


protected int minutes; 
protected int hour; 
protected boolean AM; 


public Clock() 


af 
hour = 12; 
minutes = 0; 
AM = true; 

ti 


public Clock(int theHour, int theMin, 
boolean theAM) 
ae 
hour = theHour; 
minutes = theMin; 
AM = theAM; 


public void PrintClock() 
{ 
System.out.print("Time is " + hour + ":"); 
if (minutes <= 9) 
System.out.print ("0") ; 
System.out.print(minutes + " "); 
if (AM == true) 
System.out.println("AM.") ; 
else // AM == false 
System.out.println("PM.") ; 


Now, in PreciseClock, we don’t need to settle for 
writing a PrintPreciseClock() method — we can write 
our own PrintClock() method, which will replace the 
definition of PrintClock() that we inherited from Clock (). 


public class PreciseClock extends Clock 
{ 


private int seconds; 


public PreciseClock() 
{ 

super () ; 

seconds = 0; 


} 


public PreciseClock(int hr, int min, 
int sec, boolean theAM) 
if 
super(hr, min, theAM) ; 
seconds = sec; 


// replaces definition from Clock!!! 
public void PrintClock() 
{ 
System.out.print("Time is " + hour + ":"); 
if (minutes <=9) 
System.out.print ("0") ; 
System.out.print(minutes + ":"); 
if (seconds <= 9) 
System.out.print("0") ; 
System.out.print(seconds + " "); 
if (AM == true) 
System.out.println("AM.") ; 
else // AM == false 
System.out.println("PM.") ; 


Clock cl; 
ci = new Clock(); 
c1.PrintClock() ; 


Ct td) 


uses Clock’s version of PrintClock() 


PreciseClock pl; 
pi = new PreciseClock() ; 
pi.PrintClock() ; 


Ct td) 


uses PreciseClock’s version of PrintClock(); 


So, the idea is that if the superclass has a method — and 
of course that method as a name, or otherwise it wouldn't 
be a method!!! — then that method name is supported 
by the subclass as well. Now, that subclass might have 
inherited the superclass’s definition of that method name, 
or it might have overwritten the superclass’s definition of 
that method name with its own definition instead. But 
either way, the subclass has a definition for that method 
name from the superclass. 

Meaning, your subclass cannot refuse to inherit any 
of the method names from the superclass!!!! ‘The sub- 
class can overwrite the definitions of those names, but if 
the subclass does overwrite a superclass definition, it now 
is providing its own definition, meaning it is stell support- 
ing that method name. And if it does not overwrite the 
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definition from the superclass — i.e. if it does not provide 
its own definition for that method name — then it is forced 
to accept the superclass definition that it inherited. 

There is no third option to say, “I, the subclass, don’t 
want to implement this method myself, but I refuse to 
inherit the superclass’s definition either”. The only way 
the subclass can refuse the superclass’s definition is to 
provide its own. Therefore, if we have a method in the 
superclass, then we know the subclass will have some 
definition for it as well. 


Why do we care? 
Well, due to that, it means we can give superclass ref- 
erences the ability to refer to subclass objects! 


Clock cl; 


rn 


reference to superclass type 


ci = new PreciseClock() ; 


PRR HRA AAA AA AAA AAA HA 


object of subclass type 


c1.PrintClock() ; 
this method was supported in 
the superclass, so we know it 
must also be supported in the 
subclass. Which is good, 
because it is the subclass 
version that is used. 


Above, we know the call c1.PrintClock() will work, 
because c1 is a reference of type Clock and PrintClock() 
is a method of the Clock class. So, we know that no 
matter what c1 actually points to — Clock object or 
PreciseClock object — the PrintClock() method will 
be supported. Even subclasses of Clock have to have 
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some definition of PrintClock(), and so ci can safely 
point to objects of subclasses of Clock as well as pointing 
to objects of type Clock. 

Above, since c1 points to a subclass object, the sub- 
class definition of PrintClock() is the one that is used. 

Now, that one is easy! — you can see in the code that the 
reference points to a subclass object, so deciding which 
definition of PrintClock() gets used — superclass defi- 
nition or subclass definition — is not difficult. If the rule 
is that we tie our choice of defintion to the object instead 
of the reference — and that zs our rule — then clearly, it 
must be the subclass definition that gets used, because 
clearly, the reference refers to a subclass object. So, the 
compiler could (it won’t, as we will see in a second, but it 
could) figure out from the code that c1 points to a sub- 
class object, and could then write the subclass definition 
of PrintClock() into the compiled code. 








But what happens here... 





e if the user enters a 0 for x? 





e if the user enters a 1 for x? 


int x = Keyboard.readInt() ; 


Clock cl; 
if (x == 0) 

cil = new Clock(); 
else 


ci = new PreciseClock() ; 


c1.PrintClock() ; 


Note this important fact — in the code above, the com- 
piler CANNOT determine which version of PrintClock() 
to use. This is because the type of the object pointed to 
by c1 is entirely dependent on user input, which the com- 
piler doesn’t have because that data is only supplied once 
the program actually runs! 

So, the compiler can’t figure out which method defini- 
tion to use!!! 


Dynamic binding 


e static binding — method definition chosen at compile 
time 

e dynamic binding — method definition chosen at run 
time 


The idea is, the method name is matched to the refer- 
ence type at compile time. In both the “easy” example 
above (without the if) and the harder one (with the 
if), the compiler confirms that PrintClock() is in- 
deed a method name associated with the Clock class, 
and ci is of type Clock, so whatever c1 refers to — 
Clock object or a subclass object — the PrintClock() 
method will be supported (because remember, subclasses 
can’t refuse to support superclass names). So, the call 
c1.PrintClock() will be safe no matter what object 
c1 points to. The compiler confirms that. 

But, it does not want to spend the time tracing through 
your code trying to figure out what type of object c1 
actually points to — superclass object or subclass object 
— and in some cases it actually can’t (as with the if 
example). And so the definition choice is left for run- 
time. Dynamic binding is when the method definition 
is bound to the method name at run-time, by the virtual 
machine, and not at compile-time by the compiler. 





So, the rules are: 
e Method name matched to reference type at compile- 
time 
e Method definition matched to object type at run-time 
So, we can have superclass references point to subclass 
objects all over our code, and the appropriate method 


definition will always be chosen. Next time, we will see 
why this is helpful. 


